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Enhancements to on-line transac- 
tion processing (OLTP) for distributed 
computing environments. Improved 
mechanisms for implementing OLTP 
systems which are hardware and operat- 
ing system independent and which pro- 
vide flexibility in architectural design. 
Remote clients may transparently com- 
municate with OLTP software through 
a versatile remote procedure call imple- 
mentation. Network bandwidth usage 
is minimized through a dispatcher func- 
tion which groups client transactions at 
a dispatcher service. Message passing 
is handled through flexible message ob- 
ject technology which is data type and 
operating system independent. Finally, 
a WORLD WIDE WEB browser inter- 
face is created for connecting various 
user clients to appropriately configured 
OLTP systems. 
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METHOD AND APPARATUS FOR IMPROVED TRANSACTION PROCESSING 
IN A DISTRIBUTED COMPUTING ENVIRONMENT 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

5 The present invention relates to on-line transaction 

processing (OLTP) in distributed computing environments. More 
particularly, the present invention relates to improvements 
and enhancements to OLTP techniques for transaction handling 
in a heterogeneous computing environment . 

10 

2 . Background of the Invention 

Business-critical software applications are 
generally transaction oriented and have exacting performance, 
integrity and administrative requirements. These requirements 

15 dictate an architected approach to application development, 
deployment and operation. In recent years, a component 
software model has emerged from the software industry to 
provide an architectural solution to business-critical 
processing in distributed computing environments which perform 

20 on-line transaction processing (OLTP) . Newer OLTP 

architectures carry forward the legacy mainframe attributes of 
availability, integrity, performance, scalability and 
manageability, but in true distributed applications. 
Implementations of a component -based OLTP application design 

25 creates a "virtual mainframe" from heterogeneous computing 
resources thus providing a managed coupling of resources at 
the distributed application level. 
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In a distributed computing environment, each 
application must be able to communicate and exchange 
information with other applications or machines in the 
environment. If all of the machines are based on the same 
5 hardware platform, use the same operating system, and are 
interconnected using a single network architecture and 
communication protocol, connection and communication between 
applications and/or machines is straight forward. However, 
this ideal is seldom achieved. There are many different, 
10 often mutually incompatible, computer architectures, hardware 
platforms, operating systems, and application languages 
utilized for various functions in a distributed OLTP system. 
This heterogeneity presents an obstacle to the connectivity 
and interoperability of the systems. 

15 Many organizations now recognize that the component 

software model is the logical evolution of early distributed 
computing efforts. Mainframe and centralized mid-range 
application systems are now augmented by a large base of 
powerful desktop and server systems. These distributed 

2 0 systems are loosely coupled at the network level by standard 

network transports, and form a network computing resource 
infrastructure. Initially, this infrastructure served to 
migrate "front -of f ice" applications from the centralized 
systems, largely the document processing and email 
25 communication applications easily implemented within desktop 
processors and file servers. Next, two- tier client-server 
database applications that also utilized the distributed 
environment were deployed at the departmental level These 
applications supported finer granularity at the data level, 

3 0 moving from interactive file sharing to concurrent data 

element access. These first client-server applications 
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provided proof -of -concept for true distributed application 
processing, but remained ad hoc in nature and of limited scale 
and manageability. Effective distributed processing for 
larger, more business-critical applications requires a shift 
5 from the previous client -database only approach. 

The component software model .extends client-server 
computing by supporting application partitioning to more 
effectively develop and deploy application core logic and 
manage its reliable execution in a network environment. The 

10 component software model's three-tier architecture promotes a 
clean separation of functionality: presentation/user 
interaction., core application, logic and data management. This 
separation confers benefits to the application developer and 
supports optimized execution of the overall distributed 

15 application. The development benefit of the decoupling 

presentation and core application logic is twofold and grows 
proportionally with the number of clients participating in the 
application. First, component development allows application 
designers to focus on encapsulating core application functions 

20 in their workflow and interaction. Second, clean 

presentation/application logic functional separation supports 
productive life cycle management of the application code. 
Frequent distribution of updated desktop applications to 
hundreds of clients is a serious maintenance problem for many 

25 client-server applications. 

With the component software model, presentation 
elements such as data input and display means are decoupled 
from the internals of the application operating logic. 
Changes to application logic encapsulated in the various 
30 services often will not require a change in the client side 
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application. In recent years, several vendors have developed 
component software OLTP architectures including the Tuxedo® 
system from Novell and the Encina® system from Transarc 
Corporation. While these systems overcome a number of 
5 disadvantages of prior distributed computing environments they 
leave unresolved several issues such as the growing trend 
toward ever "thinner" client applications, and create one new 
disadvantage which is a potential dependence upon a particular 
vendor of OLTP technologies. In addition, the existing OLTP 

10 platforms leave unresolved certain problems generated by the 
interaction of differing hardware and operating system 
platforms and the need to minimize the usage of a limited 
resource which is network bandwidth. Thus, there is room for 
improvement in the development of business-critical 

15 distributed computing environment platforms. 
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SUMMARY OF THE INVENTION 

The drawbacks of the existing on-line transaction 
processing (OLTP) systems are overcome by the methods and 
5 apparatus of the present invention. In a first aspect of the 
present invention, a mechanism is provided for the seamless 
separation of client software from a subsequent layer of 
client or server software in the OLTP system. The remote user 
client and the system to which it must communicate are each 

10 provided with a layer of interface logic whereby the remote 
client software has its calls to the application service 
software trapped by a remote procedure call layer. The remote 
procedure call layer is implemented to create a connection to 
the core service system upon which the application level 

15 software is operating for transferring the appropriate calls. 
The invoked service routines are then carried out by the 
application in a manner which is transparent to the fact that 
the initiating client is remote. 

In another aspect of the present invention, network 
2 0 communications between client applications and OLTP service 

applications is minimized by introducing an additional service 
application which translates single client instructions into 
multiple server transactions and takes responsibility for 
transaction management in calling the other server processes 
25 thus minimizing the interaction between a client and the 

various server services as well as minimizing the size of the 
client application code. This dispatcher service is table 
driven and uses such tables to map the single client 
procedural call to the multiple application transaction 
30 services. This also provides for an efficient mechanism of 
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changing the sequence and operations carried out at the server 
without having to change client application software. 

In yet another aspect of the present invention, 
certain incompatibilities between differing hardware and 
5 operating system platforms are handled in a transparent manner 
which improves the flexibility of message passing in the OLTP 
system. Rather than using the tightly coupled message passing 
schemes promoted by OLTP system vendors, a dynamic messaging 
scheme is provided which creates a message object for sending 

10 messages between the client and server applications which are 
data-type independent as well as content order independent. 
This aspect of the invention allows applications running on 
numerous different operating systems on different hardware 
platforms to interact in a seamless manner while providing 

15 application developers the opportunity to be flexible in 
defining their message passing requirements. 

In a final aspect of the present invention, the 
effort to create a "thin" client is taken to the extreme by 
introducing an OLTP service which provides a world wide web 

2 0 interface to the OLTP system. This is known as an HTML web 
API which allows remote users access to the OLTP system 
through nothing more than an off-the-shelf web browser. The 
above -described message object is the key to the HTML 
transaction API. By invoking a CGI program or script in 

25 response to the HTML request, the web server is capable of 
operating as the OLTP client to the rest of the OLTP system 
while providing web server functionality to the web browser 
client. The CGI interface interprets OLTP requests from the 
HTML pages which are parsed with a specified nomenclature to 

30 create the OLTP message objects which are then provided to the 
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OLTP system for transaction processing. Similarly, the CGI 
interface is. used to generate the HTML response to the web 
browser. One technique implemented is to embed the HTML 
extensions in HTML comment fields, marked by special 
5 delimiters. The result is to allow an end user access to the 
OLTP system with nothing but a commercial, off-the-shelf web 
browser. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The objects, features and advantages of the present 
invention will be apparent from the following detailed 
5 description in which: 

Figure 1 illustrates a logical diagram of an OLTP 
system architecture . 

Figure 2 illustrates a computer system architecture 
in which OLTP client software is implemented in the same 
10 computer system as the OLTP service software. 

Figure 3 illustrates one embodiment of an aspect of 
the present invention wherein the client application for the 
OLTP system is made transparently remote from the OLTP service 
portion of the OLTP software. 

15 Figure 4 illustrates an OLTP system implementing a 

dispatcher service functioning in accordance with another 
aspect of the present invention. 

Figure 5 demonstrates an example message exchange 
between a client and a specified service using a message 
object generated in accordance with the teachings of the 
present invention. 

Figure 6 illustrates the interaction of a 
workstation operating a web browser with a web server over the 
Internet's World Wide Web. 



20 
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Figures 7(a) and (b) illustrate alternative 
embodiments of an HTML server configured to interact with the 
OLTP system of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

Methods and apparatus are disclosed for an on-line 
transaction processing (OLTP) system implemented in a 
5 distributed computing environment. Throughout this detailed 
description, numerous details are set forth such as specific 
data types and various communication protocols in order to 
provide a thorough understanding of the present invention. To 
one skilled in the art, however, it will be understood that 

10 the present invention may be practiced without such specific 
details. In other instances, well-known structures and 
devices have not been shown in detail in order not to obscure 
the present invention. In particular, much of the 
functionality to be described herein is carried out by 

15 software running on various computer related components in a 
transaction processing system. With current software 
development techniques and component and object-oriented 
approaches to software architecture, - the description of 
component software products does not generally require the 

20 presentation of fully detailed source code listings. The 

explanations of logical functions to be carried out by various 
software components and their interaction with other portions 
of the system are sufficient to allow software designers of 
ordinary skill to design systems meeting the functional 

25 requirements. Accordingly, the present invention will be 

described primarily in terms of the various functionality to 
be implemented by various components of the transaction 
processing system. Those of ordinary skill in the art, once 
given the following descriptions of the various functions to 

3 0 be carried out by the present invention will be able to 
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implement the necessary programming logic in various 
programming languages or through other techniques without 
undue experimentation. 

A portion of the disclosure of this patent document 
5 contains material which may be subject to copyright 

protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent disclosure as 
it appears in the Patent and Trademark Office patent files or 
records, but otherwise reserves all copyrights whatsoever. 

Referring now to Figure 1, there is illustrated an 
exemplary OLTP system 100. In an OLTP distributed computing 
environment client application components provide user 
interface routines and transaction request services. 
Application services encapsulate core processing logic, 
providing services such as transactional data access and 
updates, etc. The OLTP services fulfill transactional 
requests by interacting with resource managers, which may 
include database systems provided by companies such as Oracle 
and Sybase, etc. Thus, in Figure 1 there is illustrated 
client applications 105 and 110 which may operate on 
workstations or other intelligent desktops such as Unix, 
DOS/Windows, MAC, or OS/2 systems and may also include point- 
of-sale terminals, automated teller machines and other devices 
optimized for specific data gathering and presentation 
functions . 

The primary client function is to gather information 
for subsequent processing and to display information either 
input or returned as the result of transaction processing. 
Transaction functions are accessed as named services 
30 advertised to the client application. The client application 
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generates and packages request messages which are directed to 
a specific application service. One aspect of the present 
invention that will be discussed more fully below is a robust 
message passing mechanism which allows for otherwise 
5 incompatible operating systems and hardware platforms to 
communicate in a transparent manner. In large-scale 
applications, many clients may concurrently request 
transactions from the OLTP service components for processing 
by the respective encapsulated services. 

10 The exemplary OLTP system illustrated in Figure 1 

shows three OLTP service applications 120 , 125 and 130 each 
respectively available to perform services advertised to the 
clients 105 and 110. Application service components 
encapsulate the core logic of their respective functions in 

15 the form of named service routines. Service routines are 
typically dedicated to a single type of task. Service 
routines encapsulate data access, for example, by including 
embedded SQL or database stored procedure logic. Clients may 
request data update or retrieval in the form of a service 

20 request to the particular server or service application 
arbitrates resource manager interaction on behalf of the 
client. A server component may advertise multiple individual 
service routines, each of which may be specifically invoked by 
an authorized client application. The distributed computing 

2 5 environment OLTP system typically comprises one or more 

application service components, each grouping the service 
routines for a related group of actions or tasks constituting 
an identifiable transactional function. Any number of 
concurrent, authorized clients may issue requests for service 

30 from the server application tier. A number of existing OLTP 
managers such as Tuxedo® and Encina® mentioned above provide 
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lower level mechanisms for service tracking, priorities, load 
balancing and available resource checking for their costing 
and scheduling decisions. 

In general, application services are dedicated to 
5 individual resource managers, although multiple application 

services may access the same resource manager. Thus, there is 
illustrated in the exemplary embodiment of an OLTP system in 
Figure 1 a resource manager 14 0 which is configured to 
communicate with application services 120 and 125, 

10 respectively. The second resource manager 150 is shown as a 

resource manager for application service 130. Data are stored 
in data "resource manager" such as resource managers 14 0 and 
150 which may be relational databases, indexed file systems, 
store and forward queue systems and other such resources. The 

15 application service level software such as servers 120, 12 5 
and 13 0 service routines as a "clients" to the various 
resource managers or data servers issuing the SQL, 
enqueue /dequeue requests or other appropriate data access 
protocols for the specific resource manager. 

2 0 OLTP systems in implemented embodiments are 

generally far more complex than the exemplary embodiment 
illustrated in Figure 1. In fully operational systems, there 
may be thousands of client applications communicating with 
many application services and numerous resource managers. In 
25 addition, the calls to one application service may implicate 
calls to other application services which may implicate 
interactions with multiple resource managers servicing a 
single set of procedure calls from a client application. In 
addition, multiple instances of service routines may be 

3 0 required with the number varying as loads change and the 
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system requirements dynamically change. It is the nature of 
having to handle multiple resource managers which has led to 
the most dramatic changes in OLTP services. Particularly, the 
ability to have a two-phase commit sequence. In a two-phase 
5 commit architecture, it is possible to rollback the state of 
the system to a synchronization point if a commit instruction 
to any of the resource managers fail. An industry standard 
interface, known as the XA interface, supports a two-phase 
commit which allows such complex OLTP systems. Much of the 
10 teachings of the present invention are directed toward XA 
compliant OLTP architectures. 



Remote Procedure Call Support For Remote Clients 

One common drawback to existing OLTP systems are the 

15 mechanisms for providing a client interface with the core 
service routines as embodied on a single server machine. 
While the single machine may be able to support multiple 
server processes, it is desirable to provide a simple 
mechanism for a client application to be on a remote machine 

20 from the machine executing the service routines. Figure 2 

illustrates a prior art configuration of an OLTP application 
service in which a single Machine A 200 supports an OLTP 
server core for calling multiple service function instances or 
procedures 22 0 which in turn communicate with database 

25 resource manager interfaces 230 to direct resource requests to 
a resource manager 240. In the early prior art system of 
Figure 2, the OLTP client application resides on the Machine A 
as OLTP client 205. The OLTP client 205 in the prior art is 
tightly coupled to Machine A for invoking advertised services 

30 220 for functions to be carried out at resource manager 240. 
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In this system, the service applications are required to be 
running on the same Machine A as the OLTP client application 
205 . 

Figure 3 illustrates an architectural level diagram 
5 of a mechanism of the present invention for removing the OLTP 
client application core from Machine A 2 00 to a remote 
Machine B 300. In this case, the OLTP client 300 makes the 
same OLTP procedure calls as the client 205 so that they may 
utilize the same code that was compiled on Machine A 200, but 

10 compiled to run independently on Machine B 300. However, in 
the utilization of a remote client, there is introduced a 
Client RPC interface 305 on Machine B 300 and a Client RPC 
interface 310 on Machine A 200. The Client RPC routine 305 
traps calls to the OLTP service core 210 that are made by the 

15 OLTP client application 300. The Client RPC routine 305 
creates a socket connection to Machine A 20 0 over the 
communication network linking Machines A and B for forwarding 
the OLTP service requests to the Client RPC code 310 on 
Machine A. This provides an interface to a portion of the 

20 client application 320 remaining on Machine A 200 which is 
responsible for presenting OLTP service calls to the OLTP 
service core 210. 

A Dispatcher Service For Minimizing Client Messaging 

25 In a structured software architectures supporting a 

distributed computing environment, it is desirable to make the 
client applications as "thin" as possible. That is, it is 
better to have as much processing logic as possible in server- 
based programs which occur in much fewer instances than in 

30 client-based applications which are much more cumbersome and 
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voluminous in nature when it comes to upgrading and 
refinements. Another object of distributed computing 
environments is to implement mechanisms which reduce the 
amount of inter-application communication because network 
5 resources are limited. Client applications should be 
prevented, whenever possible, from monopolizing such 
resources. There is thus disclosed in Figure 4 an exemplary 
OLTP system which provides a refinement to existing OLTP 
systems in order to minimize the number of transactions 

10 between the client and the server levels of the OLTP system 
and which provides additional advantages . In the exemplary 
embodiment OLTP system 400, two server routines or service 
applications are illustrated: the Procedure One Service 410 
and the Procedure Two Service 420. The client application 405 

15 may present transaction options to a OLTP that require 

invocation of multiple server-based application services such 
as services 410 and 420. Not illustrated in Figure 4 are the 
resource managers to which the respective service procedures 
410 and 420 would direct their respective data requests. 

20 The illustrated OLTP system 400 of Figure 4 also 

shows a facet of OLTP systems wherein multiple instances of 
various service procedures may be executing. In this example, 
application service 410 is shown operating with two instances 
and application service 42 0 is shown operating with three 

25 instances. This allows multiple clients to call a service 
application and reduces the odds that the service will be 
busy. 

When a service application begins executing, it 
broadcasts its availability and associated information such as 
3 0 resource manager information and available service procedures 
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to a bulletin board service 430. The bulletin board service 
430 creates and maintains a table 435 that identifies all 
operating services in the OLTP system and whether or not the 
particular service is busy. Thus, table 435 illustrates that 
5 instance one of Procedure One is busy, denoted by a X B' in the 
table, while instance two of Procedure One is ready denoted by 
an X R' . Similarly, in the example illustrated in Figure 4 all 
three instances of Procedure Two are shown to be ready to 
receive calls. 

10 An enhancement to OLTP systems illustrated in the 

OLTP system 400 is the introduction of a Dispatcher service 
440. The function of the Dispatcher service 440 is to group 
together sequences of service invocations thus reducing the 
amount of processing necessary by the client application 405 

15 and reducing the number of messages transmitted from and to 
the client application 405. The Dispatcher service 440 
maintains a table 445 which associates the client call with 
the actual service procedure calls to be executed. Thus, if a 
client application transaction actually implicates two service 

2 0 procedures, it need make only a single transaction call to a 
designated service name and the Dispatcher service 440 will 
look up in table 445 the actual service procedures to invoke 
to initiate the appropriate service application. In this 
context, the Dispatcher service 440 coordinates with the 

25 bulletin board service 43 0 to select a managed server process 
to make sure the procedure calls wind up in the correct 
service procedure queue. The collective reply messages from 
the multiple service procedures may then be received by the 
Dispatcher service 400 and lumped into a single reply message 

30 back to the client application 405, thus minimizing the number 
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of messages passed between the client application level and 
server application level of the OLTP system. 

By implementing a dispatcher service that is table 
driven, it is possible to dynamically map requests to 
5 different managed servers without requiring updates to client 
applications software. Thus, if an improved Procedure One 
service is provided elsewhere in the OLTP system, the table 
44 5 can be updated to identify an alternative application 
server which will have presumably broadcast to the bulletin 
10 board service 430 that it is available. 

Hardware And Operating System Independent Transparent Message 
Object Passing Mechanism 

One impediment to a truly flexible, scaleable OLTP 
15 distributed computing environment is dealing with the fact 

that different computer platforms running different operating 
systems often define various data types differently. For 
example, a Unix based machine may define an integer to be a 
four byte piece of data with the order of data occurring from 
20 high byte to low byte. In contrast, a PC-based machine may 

define an integer data type to be two bytes long, ordered from 
low byte to high byte. The present invention provides a 
message passing scheme which is transparent to hardware and 
operating system platforms and does not require a tight 
25 coupling between client and server applications. 

.A conventional OLTP message passing call might look 
like something: 
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OLTPcall ( "ServiceName" , ibuff, ibl, 
obuff, obi, flags) 

Such a call exemplifies prior message passing 
techniques used by many OLTP systems where the data sent to a 
5 particular service application, in this case "ServiceName" , is 
a raw data buffer, ibuff , which must be correctly interpreted 
and decoded by the receiving server. In the case where the 
server operates in a different operating system or different 
hardware platform, it must be programmed to be aware of the 

10 order and data types for the information presented. Similarly 
the return buffer, obuff, suffers the same constraints because 
it must be properly decoded by the client application machine 
to ensure proper data passing. Other OLTP systems provides 
specific routines to code the message buffers in such a way as 

15 to be decoded automatically by the OLTP core software when the 
buffer is sent to another hardware platform. However, these 
other buffering schemes are still very tightly coupled between 
the client and the server code in that they dictate very 
precise data ordering rules . 

20 In accordance with an aspect of the present 

invention, a dynamic message passing scheme is disclosed in 
which message buffers may be readily interpreted because the 
data type information is included in the message buffer and is 
transmitted with the message to the remote application code. 

25 Using an object oriented programming language such as C++, it 
is possible to create a message object containing all of the 
relevant information. Figure 5 illustrates an example of a 
screen update application on a work station for a financial 
transaction. At the Client Machine A 500, the client 

3 0 application provides an interface by which a user may enter 
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the user's name and account number on the display screen at 
505. Then,, at step 510 the user name and account number are 
taken from the screen and placed into a message object 575 and 
sent to an application service, in this example titled the 
Accountlnfo Service which runs on the account information 
server Machine B 520. The application service at step 530 
retrieves the account number and name from the provided 
message object and generates a transaction request to the 
resource manager 54 0 to retrieve the account balance. Then, 
at step 550 the Accountlnfo service takes the data from the 
resource manager and adds that to the message object 575 which 
is then returned to the client application at Machine A 500. 
At step 560, the account balance is retrieved from the message 
object 575 which has been received and is presented back to 
15 the user interface for presentation to the user. 

For the example of Figure 5, the message object is 
created by a C++ object, in this case called OLTPMsg, which in 
essence provides the following C++ calls: 

OLTPMsg. Put (DE_USERNAME, Gary Laxton) 

2 0 OLTPMsg. Put (DE_ACCOUNT_NUMBER, 123456) 

The application stores the provided data in the 
message object, is graphically illustrated by object 575 of 
Figure 5. The buffer is filled with the identification of the 
data variable, its data type, its length and the particular 
25 data. Thus, regardless of the kind of machine running the 

client application at Machine A or the server application at 
Machine B, the data type for the variables conveyed with the 
data itself is provided in a manner that each operating system 
can resolve upon reading. After the input data has been put 
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into the message object 575, the service procedure Account Info 
is engaged by another call to OLTPMsg such as: 

OLTPMsg . SendMsg (Account Info) 

which transmits the message object 575 to the OLTP service 
5 named in the SendMsg routine . 

This method of generating a message object allows 
the client to change the message by adding different fields 
etc. without having to recompile the service application code. 
It also allows the message object to be filled in a matter 

10 that is order independent. When the Accountlnfo service 520 

receives the message object, it may retrieve the values placed 
therein by calls to OLTPMsg . Get ( x name of variable') . The 
server will then do an OLTPMsg. Put to place the retrieved data 
into the field DE_ACCOUNT_BALANCE and return that to the 

15 application Machine A. Similarly, client application will 
retrieve the value returned with a call such as: 

OLTPMsg .Get ( DE_ACCOUNT_BALANCE , 
return__val) 

which will return the account balance to the user interface 
20 for presentation. 

Thus, by using a C++ like message object for data 
passing between machines, data type transparency and operating 
system/machine transparency are provided. Further, the order 
and sequence in which data are placed in the message object 
25 are inconsequential to either the operation of the client 
application or the server application. 
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World Wide Web Client API For Use With OLTP System 

In recent years there has been a dramatic shift in 
the way in which computers are used and data is accessed. 
Network technologies have expanded the interconnectivity of 
5 the computer world providing almost immediate access to 

information stored anywhere in the world to be displayed on a 
local desktop almost anywhere else in the world. The sudden 
super vitalization of the Internet and the popular mechanism 
for utilizing it known as the World Wide Web have completely 
10 changed the notion of client server technologies. Today, the 
notion of an extremely thin client is exemplified by personal 
computers running World Wide Web browsers such as Netscape 
Navigator and Internet Explorer by Microsoft. Applications 
may be written entirely for operation on a web server for 
15 presentation and operation on a user's computer without ever 
having to change or install new software at the user client. 

Figure 6 illustrates an exemplary World Wide Web 
computing environment 600. In operation, a user may use a 
personal computer or workstation 610 which includes its 
standard operating system software 615 over which runs web 
browser software 620. The web browser 620 provides an 
interface for a user to specify by name or address a location 
on the World Wide Web which contains a server to which the 
user desires to connect. In what is becoming common 
terminology, the user of user station 610 provides a universal 
resource locator (URL) which the web browser 620 uses to 
initiate the connection to the desired server 630. The web 
browser 620 communicates with the desired server over the 
Internet or Intranet 620 or other implemented computer network 
utilizing a standard protocol referred to as the hypertext 



25 
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transport protocol (HTTP) . The machine with which the web 
browser communicates is generally a server 630 running web 
server software 64 0 which is responsible for connecting the 
server to the Internet 625 for communication with remote web 
5 browsers anywhere in the world. The web server software 64 0 
provides rendering instructions with presentation materials 
defined in accordance with the hypertext markup language 
(HTML) to the web browser 620 over the Internet 625 using 
HTTP. These are frequently referred to as a HTML pages. 

10 Use of the World Wide Web today has become 

increasingly interactive. A user may provide information 
through a user interface on the web browser which can be 
packaged and transported over the Internet to the web server 
640. This may effect the selection or presentation of the 
15 HTML pages 650 which return information back to the web 

browser 62 0. HTML has been created to be a fairly simple 
programming language which allows people who are less than 
fully trained software engineers to create dynamic programs 
for presentation to end users on their web browsers. 

There is another mechanism that makes World Wide Web 
programming extremely dynamic, and that is the Common Gateway 
Interface (CGI) which is a programming interface provided by 
web servers to allow calls to external procedures outside of 
the web server software. Thus, rather than strictly 
retrieving and returning HTML pages 650, the web server 640 
may interact with CGI programs 660 which provide a more 
dynamic programming environment. CGI programming is 
substantially more complex than HTML programming and requires 
a greater proficiency and training in software engineering. A 
CGI programmer will generate results to be presented on a web 
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browser by programming the various CGI logic to be carried out 
while building a resulting HTML page to provide to the web 
server 640 for return to the web browser 620. One 
disadvantage to CGI programming, obviously, is that it 
5 sacrifices the ability to let more designed-oriented 

individuals who are capable of HTML programming from creating 
products which require CGI techniques. 

In another aspect of the present invention, a 
mechanism is provided which allows for a more robust 

10 interaction between HTML pages designed by an HTML designer 
and CGI programs developed by CGI programmers. In addition, 
this aspect of the present invention allows a web server to 
operate as a "client" to the above-described OLTP systems 
while implementing the extremely, thin client approach provided 

15 by the World Wide Web. 

The message object technology described in the 
previous section is a key ingredient to the HTML extensions 
provided by the present invention. 

As described, there is a special interface, CGI, 

2 0 supported by web servers that allows a developer to satisfy 

web browser requests programatically . To accomplish this the 
web server sends the requests to a user specified program (CGI 
script) which can format data into HTML form to be returned to 
the browser for display on the user screen. To make a web 
25 server capable of interacting with the OLTP systems of the 
present invention, the CGI interface is used to receive 
requests from the browser and format them in an appropriate 
message objects to send to the OLTP system. Figures 7(a) and 
7 (b) show two alternate embodiments for a web server 

3 0 implemented in accordance with this aspect of the present 
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invention. In Figure 7(a) the web server 700 includes web 
server application software 710 that communicates with HTML 
pages 720 and CGI programs 730. The CGI programs are written 
in such a manner that they are able to take the data provided 
by the client application web browser, package them into a 
message object such as that described above, and direct them 
to a desired OLTP service process or to the Dispatcher service 
described above with respect to Figure 4. Thus, the web 
server 710 itself becomes a "client" to the OLTP system. It 
can be seen from this architecture of Figure 7 (a) that nothing 
is required to be changed at the end-user client system in 
order to operate with the OLTP system. 

Figure 7 (b) presents an alternate architecture for 
the CGI client to the OLTP system. The alternative embodiment 
15 of Figure 7(b) is provided to off-load the OLTP processing 

from the web server because web servers can be extraordinarily 
busy responding thousands of clients over the World Wide Web. 
In this case, the CGI programs which execute OLTP calls have 
those calls trapped by the .Client RPC 3 05 which is the same 
2 0 remote procedure call technique described above with respect 
to Figure 3 . There is then introduced another machine to 
operate as a "pseudo-CGI client" 750 which includes in its 
system the Client RPC 310 which communicates with the Client 
RPC 305 and forwards the calls to OLTP service core 760 which 
25 then provides the OLTP interaction to either a Dispatcher or 
other OLTP service processors in the system. 

In accordance with this aspect of the present 
invention, extensions to HTML are provided for making 
appropriate calls for transaction message passing to the OLTP 
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system. The HTML extensions are implemented by embedding the 
extension controls in HTML comment code , 

The following describes the syntax of the language 
extensions to HTML for use with the OLTP systems in accordance 
5 with an implemented embodiment of the present inventions: 

Reserved Internal Setup Variables 

A few variables can be set in HTML that control the way the 
OLTP client processes the HTML document . These variables can 
10 be set using the HTML syntax: 

< INPUT TYPE= "HIDDEN" NAME = " IN_WEB_OUTPUT__P AGE" 
VALUE= "FILENAME . HTM" > 

Control Variables 

15 IN_WEB__OUTPUT__PAGE - Use the specified files as the template 
file. 

IN_MODE - If the mode is set to "dummy," the transaction will 
not actually be called and the default value for each variable 
will be inserted into the template file instead of the OLTP 
2 0 service output . 

OLTP Service Variables 

The variable DE_TRANS ACT 1 0N__ I D contains the name of the OLTP 
service to be called. Any variable name sent to the OLTP 
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client that starts with DE_ will be sent to the specified OLTP 
service. 

DE_TRANSACTION_ID - Name of the OLTP service to be called 
after the input variables have been set. 

5 

Extension Format 

The HTML format for a comment is of the form <!-- to begin the 
comment followed by the sequence- -> to end the comment. For 
example : 

10 <!-- This is a comment within HTML --> 

The special OLTP extended command set resides within the HTML 
comment structure. OLTP commands are preceded by a begin 
delimiter <!--${ and 'are. terminated by an end delimiter }--> as 
shown below: 

15 <! --${VARIABLE_NAME}--> 

The term u OLTP command" is used herein to specify the part of 
the HTML comment between the ${and the}, which, in the above- 
example, would be VARIABLE_NAME. The OLTP command has two 
forms : 

20 The single command form (shown above) , which specifies only 

the name of the variable to be substituted at the location of 
the command in the document . 

A longer form allows multiple commands to be performed at the 
same time. 
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The short form of the example above is equivalent to the long 
form of the command : 

< ! - - $ { F I ELD = VAR I AB LE__NAME } - - > 



5 Valid OLTP Commands 

All commands may be shortened to the least number of 
characters that would keep the command unambiguous . For 
example, the command FIELD can be shortened to F since there 
are no other commands that start with the letter "F" . 
10 Ambiguous commands are accepted on a first-come first-served 
basis; in other words, the first internal command that 
provides a match is used. 

Commands are specified in the following form: 

COMMAND = VALUE [ COMMAND = VALUE [...]] 

15 The following Table I describes the current set of supported 
commands and associated values: 
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COMMAND 


VALUE 


DESCRIPTION 


Pi e*ld 


Char strincr used as a 
valid variable name to 
indicate either an input 
variable or a variable 
from the service output . 


Insert the value of the 
specified variable into the 
HTML text. 


Type 


Numeric Date 




Source 


Input 


Set this variable from the 
URL input variables rather 

t* ha n f mm t~Vif=* OTiTP qprvi r* <=> 

v-. 1 Id 1 X X. -L. Will L- IXC ±. IT O CI- V X O C 

return values. 


Value 


Char string 


A value to insert into the 
HTML text if no value for 
this variable was returned 
from the OLTP service. 


Width 


Int 


Output width. The output 
is padded with spaces to 
the width specified. 


Repeat 


Line 


The current HTML line will 
repeat until the first 
variable in the row is not 
found in the output from 
the OLTP service. Normally 
used for creating tables. 



TABLE I 



SUBSTITUTE SHEET (RULE 26) 
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With this extension mechanism, an HTML designer can 
develop HTML pages for interacting with a web browser without 
requiring the programming skills required for CGI programming. 
5 A CGI programmer may separately interact with the HTML pages 
720 as shown in Figure 7(a) and 7(b) and extract those 
embedded commands from the HTML page, execute the OLTP 
transaction, and return the data into the HTML page. With 
this mechanism, an HTML designer can design all aspects of the 

10 presentation while putting the special comment fields where 

result data from an OLTP transaction are needed to be inserted 
using the special variable names. The CGI program will read 
the HTML page and pass it back to the web browser intact but 
operating on the embedded commands in the manner described 

15 above with respect to the operation of the overall OLTP 
system. 

In simple summary, when data is filled in by a user 
through a web browser which is exhibiting an HTML page, the 
DE_ variables are established and routed back to the web 

2 0 server which then provides the HTML page to the CGI script. 

The CGI script sees the DE_ variables and generates the 
various OLTP. Put requests to the message object and then sends 
the message object to the named OLTP service identified by the 
DE_TRANSACTION_ID . The result is then returned and inserted 
25 into the appropriate space specified in the HTML page for 

result data. This provides a robust OLTP environment with all 
the advantages of the World Wide Web wherein a client 
application is never required to be changed by the OLTP system 
administrators. Only changes in the OLTP service applications 

3 0 need be effected to change the operation seen by the end user. 
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The preceding describes numerous enhancements to 
distributed computing architectures for handling on-line 
transaction processing. Although the present invention has 
been described in terms of exemplary and implemented 
5 embodiments, it will be understood by those of ordinary skill 
in the art that many of the techniques and aspects of the 
present invention are suitable for use in other computing 
contexts. Accordingly, the spirit and scope of the present 
invention should be measured in terms of the claims which 
10 follow. 
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CLAIMS 

What is claimed is: 

11. A computer system for providing an interface between 

2 a remote client application and an on-line transaction 

3 processing (OLTP) system, said computer system comprising: 

4 server logic coupled to communicate with said remote 

5 client for receiving data for use in an OLTP transaction 

6 request; 

7 at least a first hypertext markup language (HTML) 

8 file coupled to be accessed by said server logic for delivery 

9 to said remote client, said HTML file providing rendering 

10 instructions to said remote client application for 

11 presentation to an end user, said HTML file providing for at 

12 least a first data input from said client application to be 

13 returned to said server logic; and 

14 CGI/OLTP interface processing logic coupled to 

15 communicate with said server logic to receive data 

16 representing said HTML file and said first data input, said 

17 interface processing logic for generating from said HTML file 

18 and said first input data an OLTP transaction request to be 

19 provided to said OLTP system. 

1 2 - The computer system of claim 1 wherein said computer 

2 system comprises a World Wide Web (web) server and wherein 

3 said client application comprises a web browser for 

4 communicating with said web server over a network. 

1 3 • The computer system of claim 1 wherein said 

2 interface processing logic includes means for inserting into 
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3 said HTML file result data received from said OLTP system in 

4 response to. said transaction request. 

1 4. The computer system of claim 3 wherein said 

2 interface processing logic includes means for detecting OLTP 

3 transaction request information embedded between comment 

4 delimiters in said HTML file. 

1 5. The computer system of claim 4 further comprising 

2 first application interface logic for trapping external OLTP 

3 calls generated by said CGI/OLTP interface processing logic 

4 and for forwarding said calls to a remote pseudo-CGl client of 

5 said OLTP system. 

1 6 . The computer system of claim 4 wherein said OLTP 

2 transaction request is generated by creating a message object 

3 which includes data type information with said input data for 

4 interpretation by said OLTP, system. 

17. A method of utilizing a World Wide Web (web) server 

2 as a client service to an on-line transaction processing 

3 (OLTP) system comprising the steps of: 

4 presenting a hypertext markup language (HTML) page 

5 to a remote web browser client application, said HTML page 

6 providing at least a first field to receive input data from 

7 the web browser; 

8 receiving said input data from said web browser 

9 client; 

10 parsing said HTML page to extract said input data 

11 for use in an OLTP transaction request; 
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12 generating an OLTP service call incorporating said 

13 input data; 

14 receiving result data from said OLTP service call; 

15 and 

16 forwarding said result data to said web browser 

17 client with said HTML page. 

1 8. "* The method according to claim 7. wherein said parsing 

2 step comprises the steps of: 

3 detecting an HTML comment field in said HTML page; 

4 detecting an OLTP system instruction delimiter in 

5 said comment field; and 

6 extracting the information identified by said 

7 delimiter. 

1 9. The method according to claim 8 wherein said 

2 forwarding step comprises the step of inserting . said result 

3 data into said HTML page at a point indicated by an OLTP 

4 instruction embedded in said HTML page. 

1 10. A method of utilizing an HTML document to convey 

2 non-HTML information comprising the steps of: 

3 embedding said no n -HTML information in an HTML 

4 comment field in said document; 

5 detecting said embedded information; 

6 extracting said embedded information from said HTML 

7 document ; and 

8 forwarding said embedded information to a 

9 destination configured to utilize said embedded information. 
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1 11. The method according to claim 10 wherein said 

2 embedding step comprises the steps of : 

3 embedding begin and end delimiters in said HTML 

4 comment field; and 

5 inserting said non-HTML information between said 

6 begin and end delimiters in said comment field. 

1 12. The method according to claim 11 wherein said 

2 detecting step comprises the step of detecting said begin and 

3 end delimiters in said comment field. 

1 13. The method according to claim 12 wherein said 

2 extracting step includes the step of extracting embedded 

3 information from between said begin and end delimiters. 

1 14 . A method of remotely operating a first application 

2 running on a first computer which presents procedure calls to 

3 a second application running on a second computer comprising 

4 the steps of: 

5 detecting a procedure call to said second 

6 application; 

7 trapping said procedure call with a first interface 

8 application; 

9 establishing a communication path to a second 

10 interface application operating on said second computer; and 

11 forwarding said procedure call over said 

12 communication path to said second interface application 

13 wherein said second interface application causes said 

14 procedure call- to be initiated from said second computer. 
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1 15. A method of passing data from a first application 

2 running on a first computer system operating in accordance 

3 with a first platform to a second application running on a 

4 second computer in accordance with a second platform 

5 comprising the steps of: 

6 creating a message object; 

7 putting a variable and its associated value into 

8 said message object; 

9 putting into said message object the data type of 

10 said variable and length of said associated value; and 

11 sending said message object to said second 

12 application operating on said second computer system. 

116. A method for a dispatcher system in an OLTP system 

2 to minimize the bandwidth utilized between a client 

3 application and services associated with said OLTP system 

4 comprising the steps of: 

5 receiving a transaction request from said client 

6 application wherein said transaction request implicates 

7 invocation of a plurality of said services in said. OLTP 

8 system; 

9 referring to a service table to determine which of 

10 said OLTP services to invoke in response to said transaction 

11 request; and 

12 invoking the OLTP services identified in said 

13 service table as corresponding to said transaction request. 

1 17. The method according to claim 16 further comprising 

2 the steps of: 

3 grouping any response information resulting from 

4 invoking said OLTP services; and 
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5 providing the grouped response information to said 

6 client application . 
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FIG. 5 
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FIG. 6 
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FIG. 7(b) 
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